Extending Globus to support Multicast Transmission

Proceedings of the 2004 UK e-Science All hands Meeting, 31st August - 3rd September, Nottingham UKThe Globus Toolkit is an open source software toolkit that has become the de-facto standard for middleware used to build Grid services. Globus XIO is an eXtensible Input/Output library for Globus. It provides a POSIX-like API to swappable I/O implementations - essentially "I/O plugins" for Globus. TCP-XM is a modified TCP engine that supports multicast transmission. We have taken this protocol and wrapped it using XIO to extend the Globus Toolkit to support multicast transmission. This paper describes the implementation and operation of our Globus XIO multicast transport driver. It provides an overview of the TCP-XM protocol design, and describes some initial experimental results

How to Tell When a Digital Technology Is Not Ready for You.

The stages of digital technology readiness are viewed through the lens of three contemporary and widely discussed examples, namely distributed ledger technology, machine learning, and the internet of things. I use these examples to clarify when there is really just an old technology being re-branded, when there is something genuinely new and useful, and whether there may be over-claiming

TCP in the Internet of Things: from ostracism to prominence

© 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.TCP has traditionally been neglected as a transport-layer protocol for the Internet of Things (IoT). However, recent trends and industry needs are favoring TCP presence in IoT environments. In this article, we describe the main IoT scenarios where TCP will be used. We then analyze the historically claimed issues of TCP in the IoT context. We argue that, in contrast to generally accepted wisdom, most of those possible issues fall in one of the following categories: i) are also found in well-accepted IoT end-to-end reliability mechanisms, ii) can be solved, or iii) are not actual issues. Considering the future prominent role of TCP in the IoT, we provide recommendations for lightweight TCP implementation and suitable operation in such scenarios, based on our IETF standardization work on the topic.Postprint (author's final draft

Managing Shared Access to a Spectrum Commons

The open access, unlicensed or spectrum commons approach to managing shared access to RF spectrum offers many attractive benefits, especially when implemented in conjunction with and as a complement to a regime of marketbased, flexible use, tradable licensed spectrum ([Benkler02], [Lehr04], [Werbach03]). However, as a number of critics have pointed out, implementing the unlicensed model poses difficult challenges that have not been well-addressed yet by commons advocates ([Benjam03], [Faulhab05], [Goodman04], [Hazlett01]). A successful spectrum commons will not be unregulated, but it also need not be command & control by another name. This paper seeks to address some of the implementation challenges associated with managing a spectrum commons. We focus on the minimal set of features that we believe a suitable management protocol, etiquette, or framework for a spectrum commons will need to incorporate. This includes: (1) No transmit only devices; (2) Power restrictions; (3) Common channel signaling; (4) Mechanism for handling congestion and allocating resources among users/uses in times of congestion; (5) Mechanism to support enforcement (e.g., established procedures to verify protocol is in conformance); (6) Mechanism to support reversibility of policy; and (7) Protection for privacy and security. We explain why each is necessary, examine their implications for current policy, and suggest ways in which they might be implemented. We present a framework that suggests a set of design principles for the protocols that will govern a successful commons management regime. Our design rules lead us to conclude that the appropriate Protocols for a Commons will need to be more liquid ([Reed05]) than in the past: (1) Marketbased instead of C&C; (2) Decentralized/distributed; and, (3) Adaptive and flexible (Anonymous, distributed, decentralized, and locally responsive)